Modeling system

ABSTRACT

Disclosed herein are techniques for generating textual descriptions of a graphic model and vice-versa. The techniques may be used, for example, in conjunction with a scheme that models objects and processes as independent entities. The techniques have a wide variety of applications including automatic code generation, system simulation, and language translation.

REFERENCE TO RELATED APPLICATIONS

This relates to and claims priority from co-pending U.S. ProvisionalPatent Application Ser. No. 60/201,860, filed May 4, 2000; andco-pending U.S. Provisional Patent Application Ser. No. 60/216,532,filed Jul. 5, 2000. Both applications are incorporated by referenceherein in their entirety.

BACKGROUND

Many system designs begin as ad hoc sketches on the back of a napkin.These crude diagrams attest to the value of diagramming as a designtool. A relatively simple diagram can depict important interactions andrelationships between different system components. Oftentimes, however,a drawing may later appear confusing or ambiguous to its own author.This problem often stems from a lack of notational consistency in adiagram.

A wide variety of modeling methodologies attempt to formalize themeaning associated with different diagram symbols. For example, UML(Unified Modeling Language) provides a general-purpose notationallanguage for specifying and visualizing complex software and othersystems. In particular, UML proponents advocate an approach thatrepresents a system as a collection of objects. Different types of UMLdiagrams can portray various views of the system.

Many different vendors offer design tools that ease construction ofsystem diagrams. For example, Rational Rose® provides a suite of toolsthat ease construction of UML diagrams. These tools provide a userinterface that features a palette of UML graphic symbols for placementon a diagram.

SUMMARY

In general, in one aspect, the invention features a computer-implementedmethod of modeling. The method includes receiving input specifying atleast one graphic element of a model diagram. The diagram can includegraphic elements representing a process and graphic elementsrepresenting an object. Based on the received input, the methodgenerates a textual description of the diagrammed model.

Embodiments may include one or more of the following features. Thegraphic elements may correspond to a graphical notation, such as OPM(Object-Process Methodology), that models objects and processes asindependent elements.

Generating the textual description may include determining one or morecontext-free grammar production rules corresponding to the input, andgenerating a context-free grammar expression from the one or morecontext-free grammar production rules. The production rules may beconsistent with a natural language such as English.

The received input may be user input. For example, the textualdescription may be generated as a real-time response to user inputmanipulating, adding, or deleting graphic elements. Generating thetextual description may also proceed in a batch mode.

The received input may specify a level of detail to depict.Additionally, the method may include determining a portion of thetextual description to display based on the received input specifyingthe level of detail.

The method may include translating a label of a graphic element from afirst natural language to a second natural language. Such a method mayuse production rules of a context-free grammar for the second naturallanguage.

The method may also include using the generated text to automaticallygenerate software instructions to implement the model or to provide avisual simulation of a modeled system.

In general, in another aspect, the invention features acomputer-implemented method of modeling. The method includes receiving atextual description of a model and, based on the received description,generating a model diagram composed of different graphic elements. Thedifferent graphic elements can include a graphic element representing aprocess and a graphic element representing an object.

In general, in another aspect, the invention features a method oftranslating text from a first natural language to a second naturallanguage. The method includes receiving input specifying a diagramincluding elements labeled in accordance with a first natural language,translating the element labels from the first natural language to thesecond natural language, and generating text in the second naturallanguage in accordance with a grammar associated with the diagramelements.

In general, in another aspect, the invention features a computer programproduct, disposed on a computer readable medium, for modeling. Thecomputer program includes instructions for causing a processor toreceive input specifying at least one graphic element of a modeldiagram. Different graphic elements in the diagram can include a firstgraphic element representing a process and a second graphic elementrepresenting an object. Based on the received input, the instructionscan generate a textual description of the diagrammed model.

In general, in another aspect, the invention features a computer programproduct, disposed on a computer readable medium, for modeling. Thecomputer program includes instructions for causing a processor toreceive a textual description of a model, and, based on the receiveddescription, generate a model diagram composed of different graphicelements that can include a first graphic element representing a processand a second graphic element representing an object.

Advantages will become apparent in view of the following description,including the figures and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1 to 20 are screenshots of a modeling tool that expresses a systemmodel both graphically and textually.

FIG. 21 is an OPM (Object Process Methodology) diagram illustrating OPM.

FIGS. 22 and 23 are listings of formal text corresponding to the OPMdiagram of FIG. 21.

FIG. 24 is a diagram illustrating a learning mode of the modeling tool.

FIGS. 25-30 are diagrams illustrating temporal features of OPM.

FIG. 31 is a diagram representing an elevator system.

FIGS. 32-35 are listings of code automatically generated for the diagramdepicted in FIG. 30.

FIG. 36 is a diagram illustrating a generic processing process.

FIG. 37 is a flowchart of a process for generating text based on graphicelements in a diagram.

FIG. 38 is a flowchart of a process for modifying a collection ofgraphic elements in a diagram based on text.

FIGS. 39 and 40 are screenshots of a modeling tool illustrating languagetranslation.

FIG. 41 is a diagram of a computer platform.

DETAILED DESCRIPTION

FIGS. 1 to 20 illustrate a user interface provided by a modeling tool.Each user interface screen 100 shown features a graphic design workspace102 (“DiagraMaker”). The workspace 102 enables a user to assemble andinterconnect graphic elements to model a system. As shown, the tool'suser interface may provide a palette 101 of graphic symbols representingmodel elements. For example, the tool enables a user to drag-and-dropmodel elements from the palette 101 onto the workspace 102 forconfiguration into a system model. The model elements shown in thepalette 101 of FIG. 1 correspond to a graphic notation defined by OPM(Object-Process Methodology).

Object-Process Methodology enables a user to define processes andobjects as independent entities. Independent representation of objectsand processes reflects the thought process of many designers, and, thus,facilitates rapid model development. Additionally, even those initiallyunfamiliar with OPM can quickly grasp components and behaviorrepresented by an OPM model. FIGS. 1-20 illustrate model elementsoffered by OPM. Appendix A includes a list of all such elements, theirusage, and meanings.

As shown, FIGS. 1-20 also feature a script window 104 (“TextMaker”) thatpresent the textual, formal English, equivalent of a diagram in theworkspace 102. These sentences are referred to as OPL (Object ProcessLanguage) herein. A user can enter text into the script window 104 bytyping, using speech recognition, opening a file, and so forth.

The tool can maintain the equivalence of the script window 104description and the workspace 102 diagram, whether a user alters thediagram in the workspace 102 or changes the text in the script window104. That is, the tool can alter or add graphic model elements toconform to the text description in the script window 104 and canautomatically generate sentences reflecting changes or additions to adiagram. Hence, the informational content of the text description andgraphic diagram remains equivalent. Additionally, one may be completelyreconstructed from the other.

The precise description of a modeled system provided by the text permitsreview of the design by domain experts or managers who may have littletechnological experience or prior experience with graphic models.Additionally, even though easily digested by lay people, the textprovides an unambiguous specification for system implementation, forexample, by programmers.

In general, to maintain equivalence between diagram and text, the toolassociates model elements and model element combinations with formalEnglish sentence types. As user input graphically specifies modelelements and their relationships, the modeling tool can automaticallygenerate the corresponding text sentences. Such real-time feedback canquickly alert users to unintended design errors as they occur.

The text shown conforms to a context-free grammar defined to generatenatural language (e.g., English) sentences. Appendix B includes alisting of the context free grammar production rules. Production rulescan be expressed in a wide variety of formats, such as BNF (Backus-NaurFormat), EBNF (Extended Backus-Naur format) and so forth. While therules shown feature English words and syntax, other production rules mayreflect other natural languages.

The equivalence of the text and graphic model representations is, again,a two-way street. That is, instead of generating the text from adiagram, the tool can automatically generate a system diagram from text.That is, the modeling system can use the production rules, such as therules shown in Appendix B, to parse a given statement and construct acorresponding diagram. For example, as a user translates prose systemsrequirements specification into the modeling system's context-freegrammar expressions, the tool can depict the equivalent diagram elementsin the diagram window 102. Again, the tool's use of ordinary Englishtext to describe a system increases operator familiarity, eases use, andcan speed system design. To provide a better understanding of thecorrespondence between graphics and text, the tool can highlight graphicconstructs corresponding to a sentence when the user rests a cursor onthe sentence, and vice-versa.

Though shown as a system that responds to user input in real-time, thesystem may operate in batch-mode. For example, a user may submit, oropen, a script of formal English sentences arranged in paragraphs and bepresented with the corresponding set of diagram(s), one for eachparagraph. Formal English sentences, described below, can indicate thelinks between the different diagrams. Similarly, a user may completelydraw a set of diagrams that specify a system before requesting automaticgeneration of the corresponding text. Either the real-time orbatch-modes may be implemented as an interpreter and/or a compiler.Additionally, rather than presenting a generated script or set ofdiagrams, the system may instead save such information as a file.

To illustrate OPM features and the equivalence of the graphic and textexpressions of a model, FIGS. 1-20 depict development of a weddingsystem that marries two people. While software designers can use OPM forsoftware system development, the example that follows illustrates thatOPM can represent systems in a wide variety of domains.

As shown, to model a wedding system a designer created an object 106labeled “Person” in the workspace 102. For example, the designer mayhave selected a graphic symbol of an object 103, a rectangle, from thepalette 101 and positioned the object 106 on the workspace 102.

An object 106 can have different states. A “rountangle”(“rounded-corners rectangle”) graphically depicts an object's stateinside the object's box. As shown, a designer has specified that aperson 106 object includes a state 108 labeled “single” 108 and a state110 labeled “married”. Additionally, as indicated by the bolding of the“single” 108 state's border, the designer has specified that a “Person”106 object initially assumes the “single” 108 state.

The scripting window 104 presents the formal English sentences 200, 202corresponding to the diagram depicted in the workspace 102. Otherconfigurations present the information shown in the workspace 102 andscripting window 104 in different ways. For example, the system maypermit user configuration and arrangement of the windows 102, 104, menubars, palettes 101, and so forth. Additionally, the tool need notdisplay the workspace 102 and scripting window 104 simultaneously. Thetool may also feature other windows, such as those containinghierarchical lists of previously defined objects and/or processes andtheir attributes, software instructions or database schemasautomatically generated from the script and/or diagram, and so forth.

The tool constructs the sentences presented in the scripting window 104by combining the graphic element labels with reserved phrases of one ormore words associated with a graphic element. For example, a “stateenumeration” sentence according to the production rules in Appendix Bcan be expressed as “Object can be State List” where the Object isreplaced by the object 106 label “Person” and State List is replaced bya list of the object's states' labels (i.e., “single” and “married”).Thus, as shown, the scripting window includes a text sentence 200 of“Person can be single or married”.

The tool can use text formatting to bold labeled elements while reservedphrases (e.g., “can be”) appear in a normal, non-bolded font. Thisconvention emphasizes the elements of the system rather than thereserved phrases that may appear again and again in a script. Theconvention also enables a user to quickly identify relationships betweendomain-specific names of objects, processes, and states. Additionally,the system may enable a user to color code diagram elements and formatthe text to color terms to match the color of their correspondingdiagram elements.

Again, while described as generation of text based on manipulation ofelements in the workspace 102, the tool can also accept text and modifythe graphic depiction to reflect this text. For example, formatting atext term as a specific color can cause the system to correspondinglycolor associated diagram elements.

The tool can provide feedback to guard against illegal constructs. Forexample, if a user attempts to insert a formal English sentence thatdoes not conform to the formal English syntax, the system can generate alist of the closest legal options for user selection. Likewise, if theuser attempts to insert a graphical construct not recognized by thesystem as legal, the tool can generate a list of the closest legalgraphical arrangements for user selection. In either case, the tool candirect the user to an appropriate part of a tool help/tutorial facility.

OPM permits alternate representations of similar system features. Forexample, as shown in FIG. 2, instead of directly attributing states tothe “Person” object 106, a designer can use an“exhibition-characterization” graphic element 114 to elaborate oncharacteristics exhibited by another element. The tool depicts the“exhibition-characterization” graphic element 114 as a dark trianglewithin a white triangle. As shown, the designer has added a new object116, labeled “Marital Status”, that features the states of “single” 118and “married” 120. By connecting the “Marital Status” object 116 to the“Person” object 112 via the “exhibition-characterization” graphicelement 114, the diagram expresses that a marital status characterizeseach person.

As shown, the designer also used a “non-comprehensive” symbol 112 thatindicates that a person features other characteristics which are notdepicted in the diagram. The “non-comprehensive” symbol 112 appears as aline segment crossing a connection between the person object 106 and thegraphic element 112 (i.e., the “exhibition-characterization” symbol)defining the relationship between the objects 106, 116. As shown insentence 204, the text associated with this symbol features the words“and more”. The “non-comprehensive” symbol can also be used tocharacterize other symbols such as “aggregation” and “specialization”symbols described below.

While a bit more involved than FIG. 1, the diagram of FIG. 2 permitsgreater system design flexibility. For example, a designer can easilyadd more features (attributes and/or operations) for a person.Additionally, comparing the text 204-208 of FIG. 2 with the text 200-202of FIG. 1 illustrates how different sentences can express essentiallythe same system. This flexibility enables designers to express a systemin their own style without losing the rigorous formalism provided byOPM.

FIG. 3 introduces an important aspect of OPM. As shown, a user hasinserted a process symbol 126, depicted as an ellipse, into the diagram.A process is an entity that transforms an object. As shown, the user haslabeled the process 126 “Wedding”, conforming to OPM's suggestedpractice of using the gerund form of verbs to name processes.

As shown in FIG. 3, using OPM, a designer can represent both systemprocesses 126 and objects 106 as independent “things”. Again, an objectcan include one or more possible states. A process affects an object bychanging its current state (s). Representing a system with independentobjects and processes results in an intuitive diagram reflecting bothsystem structure and dynamics. For example, even before a more formaldiscussion, many can intuit from the diagram shown in FIG. 3 that a“Wedding” changes a “Person” from “single” to “married”. A reading ofthe corresponding text 210 explicitly expresses this interoperation ofthe “Wedding” process 126 and “Person” object 106.

In greater detail, after adding and labeling the “Wedding” process 126,a user specified the transformation of the “Person” object 106 providedby the “Wedding” process 126 by a pair of links 122, 124. Each link 122,124 appears as a line terminating in hollow arrowhead. The links 122,124 have different sources and destinations. That is, link 122 leadsfrom the “single” state 108 to the “Wedding” process 126, while link 124leads from the “Wedding” process 126 to the “married” state 124. In OPMterminology, link 122 forms an “input link” that represents the leavingof the “single” state 108. Similarly, link 124 forms an output link thatrepresents entry into the “married” state 124. The pair of links 122,124 identify the “Wedding” process as changing a “Person” 106 from the“single” 108 state to “married” 110 state. As shown, the pair of links122, 124 can share a thread label (e.g., “a”) that can distinguish thispair 122, 124 from others in a diagram. Thread labels permitidentification of potentially parallel threads of execution.

As shown in FIG. 4, an element may have associated “enablers” 130, 134.An enabler 130, 134 is an object that is required for a process tooccur, but itself is not affected by the process occurrence. Forexample, a wedding requires both a justice of the peace and a marriagelicense. To reflect this, as shown in FIG. 4, a designer specified thatthe “Wedding” process 126 requires both a “Justice” enabler 130 and a“License” enabler 134. As shown, a line terminating in a “lollipop”identifies enabler relationships.

OPM and the tool can distinguish between different categories ofenablers. For example, one type of enabler is known as an “agent.” Anagent, such as a human or organizational unit, exhibits discretion.Other types of enabler's are deemed “instruments”. Blackened lollipopsidentify agents while hollow lollipops identify instruments. FIG. 4depicts the “Justice” enabler 130 as an agent and the license as aninstrument. This reflects the designer's acknowledgment that a “Justice”may exercise judgment before marrying two people, while a marriagelicense offers nothing other than its provisions. The involvement of anagent in a process can imply a need for some kind of user interface inthe ultimate system implementation.

While terms like “enablers”, “agents”, and “instruments” may require abit of explaining to those unfamiliar to OPM, the text sentences 212-214eschew this terminology in favor of simpler descriptions. For example,the text generated for the agent relationship between the “Justice”object 130 and the “Wedding” process 126 simply states “Justice handlesWedding.” 212. This concise phrasing clearly communicates the designdepicted by the diagram to those unfamiliar with OPM notation or itsterminology.

As previously described, processes transform objects by changing theirstates. For example, FIG. 3 illustrated a process 112 altering an object106 by changing an object's 106 state. As shown in FIGS. 5 and 6,processes may also construct (generate) or destroy (consume) objects.For example, a wedding generates a new couple. FIG. 5 illustrates thistransformation by the addition of a “Couple” object 138 and a link 136.While the link 136 appears identical to the “input” 122 link introducedin FIG. 3 (i.e., a line terminated by a hollow arrowhead), the contextof the link 136 imparts a different meaning. That is, since the link 136connects to the “Couple” object's 136 border instead of some internalstate, the link 136 represents construction of the object 136. Thisconstruction is analogous to a “constructor” in C++. Again, instead oftechnical lingo, the text sentence 216 corresponding to thisconstruction states “Wedding yields Couple”. This natural phrasingexpands the audience of the model to those less familiar withprogrammatic concepts.

Just as a wedding creates a couple, a divorce destroys it. Thus, FIG. 6depicts a “Divorcing” process 142 that destroys the “Couple” object 138constructed by the “Wedding” process 112. The link 140 that establishesthis relationship between the “Couple” object 138 and the “Divorcing”process 142 appears identical to the output link 124 leading from the“Wedding” process 112 to the “married” state 110. However, again thecontext of the link 140 imparts a different meaning. That is, the link140 extends to the “Divorcing” process 142 from the “Couple” object 138perimeter instead of from some internal “Couple” object 138 state. Thiscontext indicates the destination process 142 consumes the source object138. The text, “Divorcing consumes Couple” 218, states the relationshipbetween the object 138 and process 142 with blunt clarity.

A model often changes over the lifecycle of a system. Such changes occurfrequently during the initial design as users try different modelconfigurations. Such changes also occur during maintenance phases, forexample, after practice reveals deficiencies in an original model. Thetool reflects changes in the diagram or equivalent text to maintainequivalence between the two. For example, user removal of the“Divorcing” process 142 from the diagram causes removal of consumptionlink 140 and the corresponding text sentence 218. Similarly eliminationof sentence 218 causes removal of the “Divorcing” process 142 andconsumption link 140 from the diagram.

Returning to the design of the wedding system model, generally, awedding joins a man and a woman. As shown in FIG. 7, OPM provides agraphic element 140 that enables specification that “Man” 142 and“Woman” 144 objects constitute “specializations” of a “Person” object106. That is, much like class inheritance in object-orientedmethodologies, a diagram can specify that both the “Man” 142 and “Woman”144 objects share the attributes associated with the “Person” object106, though the “Man” 142 and “Woman” 144 objects may differ in otherways. For example, while both “Man” 142 and “Woman” 144 objects have“single” 108 and “married” 110 states inherited from the “Person” object106, a “Man” object 142 may have a “Best Man” object (not shown) while a“Woman” object 144 may have a “Bridesmaid” object (not shown).

As shown, OPM depicts the “specialization” symbol 140 as a hollowtriangle. The text sentence 220 associated with the specializationincludes the reserved term “are”, as in “Man and Woman are Persons.”220. The text sentence 220 also illustrates that the tool can pluralizewords as contextually needed. For example, a sentence of “Man and Womanare Person” is both awkward and grammatically incorrect. Thus, the toolpluralizes the object label “Person” by adding a “s” suffix. The toolcan maintain a dictionary for words not pluralized by convention “s” and“es” suffixes (e.g., “goose” pluralized is “geese”).

OPM provides not only for specializations of objects, but alsospecializations of processes. For example, “Secular Wedding” and“Religious Wedding” (not shown) could be specializations of the process“Wedding” just as “Man” and “Woman” are specializations of the objectPerson.

In addition to representing specializations of a generic person, acouple typically includes a man and woman. FIG. 8 illustrates an“aggregation-participation” symbol 146, a blackened triangle,identifying parts of an entity. For example, the symbol 146 identifies a“Couple” object 138 as the aggregation of “Man” object 142 and “Woman”object 144 participants. Again, the corresponding text plainlyidentifies this relationship with the text “Couple consists of Man andWoman” 222. Alternatively, to avoid confusion with UML notation, ablackened diamond may be used instead of blackened triangle 146.

FIG. 9 uses a “classification-instantiation” symbol 148, 150, a darkinverted triangle within a hollow outer triangle, to identify “Sam” 152and “Jane” 154 objects as instantiations of a “Man” 142 and “Woman” 144respectively. That is, “Sam” 152 and “Jane” 154 share the attributes ofthe “Man” 142 and “Woman” 144 objects, respectively. The sentences 224,226 corresponding to the symbol 148, 150 feature the reserved words “isan instance of” as in “Sam is an instance of Man.” 224.

OPM can distinguish between physical and informatical things. Shadowed(3-dimensional) or double-bordered boxes and ellipses denote physicalobjects and processes, respectively. As shown, the “Sam” 152 and “Jane”154 objects both appear as double-bordered rectangles. An “informatical”entity conceptually exists independently of its physical embodiment. Forexample, a song remains the same whether scored on music sheets orrecorded on vinyl. Thus, a song is an informatical entity. However,physical entities, such as a rock or body, do not have existenceseparate from its physical, space-occupying form. In practice, systemdesigners often ignore this distinction and use the single borderedinformatical graphic symbols for informatical and physical entitiesalike. OPM, nevertheless, provides such symbols if needed. In additionto its usefulness as a modeling symbol, this enables the separation ofsentences that need to be coded from those that do not (e.g., hardwareportions of a system).

As shown, an instance of an object 152, 154 is denoted as a rectanglewith a truncated upper left corner. Likewise, an instance of a processis denoted as an ellipse with a small part of its left part truncated(not shown). This provides a distinction between a thing (object orprocess) and its instances when an attachment between the instance andthing does not appear or has not yet been established.

FIG. 9 completes an initial high-level diagram of a wedding systemmodel. However, extensive diagramming can quickly introduce a confusingdegree of clutter into a diagram. To ease complexity management, thetool provides different features that enable a designer or user tobalance the level of detail revealed by a diagram against diagramsimplicity and clarity. The diagrams representing these different levelsof detail collectively represent the system as a whole.

Again, the system provides many different complexity management featuresfor use at a user's discretion, for example, when a diagram appears toopopulated with objects, processes, and links. The complexity managementfeatures include state suppression/revelation, in-zooming/out-zooming,and folding/unfolding (described below). After using a complexitymanagement feature such as a scaling feature, the tool presents a newdepiction showing more or fewer details.

As stated above, the system provides a “state suppression/revelation”mechanism where state suppression hides object states and staterevelation reveals them. For instance, in FIG. 10, a user has specifiedsuppression of states of the “Person” object 106. That is, the toolsuppresses depiction of the “single” and “married” states (108, 110)within the “Person” object 106. Additionally, the tool replaces theinput 122 and output 124 links with an “effect” link 156. The tooldepicts an “effect” link 156 as a line linking the affecting processwith that affected object that terminates with hollow arrowheads on bothends. The effect link 156 represents some unspecified effect the process112 has on the object 106. Correspondingly, instead of specifying theexact nature of change, the text merely states that “Wedding affectsPerson.” 228.

It should be noted that a user can add an effect link 156 withoutsuppressing object states. For example, the effect link 156 may appearin the graphic element palette. This is useful when the states of anobject are known but it has not yet been determined how exactly theaffecting process changes the states of the affected object.

The tool can enable a user to toggle between suppressed or revealedstates of an object, for example, by double-clicking or right-clickingon the object. Similarly, entering text of “Suppress States of Person”or “Reveal States of Person” in a command window may perform the sametask. Additionally, using similar techniques, a user may suppress orreveal the states of one, several, or all objects in a diagram.

In addition to state suppression/revelation, the tool may provide userswith the ability to “zoom” into and out-of particular elements. Toillustrate, FIG. 11 depicts a simplified version of the wedding systemmodel, labeled “SD” 158, that offers a concise, high-level presentationof major model objects, processes, and agents. The model of FIG. 11,however, lacks detail of how the “Wedding” process 126 operates.

FIG. 12 depicts the internal workings of the “Wedding” process 126 in adiagram labeled “SD1” 160. As shown, the process 126 encapsulates anumber objects 164, 174 and processes 162, 170, 180. Again, as processesand objects stand on equal methodological footing, either a process oran object may encapsulate the other. While FIG. 12 depicts objects 164,174 and processes 162, 170; 180 not shown in FIG. 11, the two FIGs. areentirely consistent and merely differ in their level of detail. Forexample, links present in the higher level diagram (FIG. 11) also appearin the more detailed diagram (FIG. 12) though the links may connect tolower-level objects and/or processes displayed.

A user can navigate from the high level diagram of FIG. 11 to thedetailed presentation of the “Wedding” process 126 in FIG. 12 byin-zooming (i.e., zooming-into) the “Wedding” process 126. Likewise, acomplementary “out-zooming” out of the “Wedding” process, can navigate auser from the detailed “Wedding” process 126 diagram, SD1, back to thehigh-level diagram, SD. Thus, instead of a planar diagram, an OPM modelhas recursive depth. That is, a user could further zoom into the“License Verifying” process 162 to define or observe elementsencapsulated by the process 162. In technical terms, a model forms ahyper-graph where each node is a diagram and each edge is a directed arcdenoting a relationship between the diagrams.

Comparing FIGS. 11 and 12 illustrate the increased detail revealed bythe “in-zooming”. For example, in addition to the encapsulated entities162, 164, 170, 172, 180, FIG. 12 depicts the links from the “Justice”agent 130, License 134 instrument, “Person” object 106, and “Couple”object 138 as extending particular “Wedding” process 126 elementsinstead of terminated at the process 126 perimeter. However, afterout-zooming, for example, from FIG. 12 to FIG. 11, the tool again showsthe links extending to the perimeter of the “Wedding” process 112.

As depicted in FIGS. 11-12, the script window 104 presents the textcorresponding to the diagram currently displayed by the workspace 102.Additionally, as shown in FIG. 12, a “zoom” sentence 230 identifies theentities encapsulated by the “Wedding” process 126 to preserve thehierarchy of detail for later use.

In greater detail, the “Wedding” process 126 includes “LicenseVerifying” 162, “Postponing” 170, “Ceremony Conducting” 172, and“Dining” 180 processes. In general, in OPM, control flows from top tobottom. That is, the relative positioning of the processes indicatesthat the “License Verifying” process 162 should occur prior to any ofthe other processes. Processes appearing at the same horizontal levelindicate processes that can, potentially, proceed in parallel.

The “Wedding” process 112 includes an object 164 labeled “License isLegal?”. The question mark indicates that the object 164 constitutes aBoolean object. A Boolean object has two mutually exclusive states 166,168. A link 160 from the “License Verifying” process 162 to the “Licenseis Legal?” object 164, again, features a line terminating in a hollowarrowpoint. In this context (i.e., a link from a process 162 to aBoolean object 164), however, the link specifies that the process 162determines the state 166, 168 of the Boolean object 162 as reflected inthe corresponding text “License Verifying determines whether License isLegal” 238.

Another link connects the “yes” state 168 of the “License is Legal”Boolean object 164 to the “Ceremony Conducting” process 172. A similarlink connects the “no” state 166 to the “Postponing” 170 process. Like“instrument” links, the links terminate in hollow lollipops. In thecontext of connecting states to processes, the links formflow-of-control “conditional” links. Additionally, since the “License isLegal?” Boolean object 164 can only be in one state at a time, the linksrepresent mutually exclusive conditions. The relationships establishedby these links are appropriately explained by the corresponding text240, “Ceremony Conducting occurs if License is Legal, otherwisePostponing occurs”. In programming language terms, the above is an“if-then-else” type statement. A diagram, or the corresponding text, canalso specify other flow-of-control constructs. For example, a user canconstruct a “case” statement construct by including more than twostates, each being a condition for triggering a process.

Again, as described above, a user can zoom-into and out-of diagramelements. For example, double-clicking the “Wedding” process 126 in FIG.11 causes the tool to replace the high level diagram with the moredetailed display of FIG. 12. However, the tool may provide othernavigation mechanisms.

For example, the tool can present multiple diagrams of a system modelsimultaneously. For example, FIG. 13 illustrates simultaneouslypresented diagram windows of the high-level model diagram 182 shown inFIG. 11 and the more detailed diagram 184 of the “Wedding” process shownin FIG. 12. The different windows need not be separate diagrams. Forexample, one window may include a diagram with suppressed states while adifferent window shows the same diagram with revealed states. Per auser's request or query, the tool can generate a new diagram thatcombines information about a particular subset of objects and/orprocesses from several different diagrams.

The tool may also present a system map window 186 that can be shown orhidden. As shown, the map 186 presents “thumbnails” 188-190 of differentmodel diagrams. Selecting one of the “thumbnails” 188-190 causes thetool to present the selected diagram in the workspace 102. The map 186,thus, provides easy navigation among the, potentially, numerous diagramsin a diagram set and allows a user to see the “big picture” whilelooking in greater detail at some portion of the system.

In addition to the complexity management features illustrated above, thetool also provides a folding/unfolding feature that remove/revealaggregation, specialization, exhibition, and instantiation symbols andrelated entities (e.g., “sub-objects” aggregated by another object).

Again, the design example above illustrated relationships provided bythe tool and OPM. Additionally, the tool and OPM also allow a user todefine a relationship between entities of their own creation. Forexample, FIGS. 14-16 show user defined relationships between a “Mother”object 300 and a “Child” object 302.

In greater detail, FIG. 14 illustrates a link 304, known as a“unidirectional structural link”, extending from a source “Mother”object 300 to a destination “Child” object 302. The link 304 label,“parent of”, expresses the relationship between the objects 300, 302.The link 304 shown features a line terminating in a “half”,harpoon-shaped, arrowhead. The “half” arrowhead identifies the link 304as a “forward” link. That is, the label describes the relationship ofthe source object 300 to the destination object 302, relative to thesource object 300. For example, as indicated by the corresponding textsentence 400, the “Mother” is parent of Child”.

FIG. 15 illustrates a bi-directional structural link 306. As shown, thelink 306 is essentially two opposite oriented unidirectional structurallinks combined. The two labels correspond to forward and backwardrelationships, respectively. As expressed by the corresponding text, thelink 306 corresponds to two different text sentences 402, 404. Namely,“Mother is parent of Child” 402 and “Child is offspring of Parent.” 404.

FIG. 16 illustrates yet another kind of structural link 308 thatexpresses a “homologous” or mutual relationship. That is, the samerelationship holds in both the forward and backward directions. Asshown, the tool depicts the link 308 as a line terminating in arrows onboth ends. This link 308 corresponds to a text sentence for the forwarddirection (“Mother is related to Child” 406) and the backward direction(“Child is related to Mother” 408).

By default, structural relationships form a one-to-one relationship,however, structural relationships, particularly in database schemas,often form one-to-many, many-to-one, and many-to-many relationships. Asshown in FIG. 17, a user has annotated a homologous structural link 310to identify a number of “Child” objects 302 related to the “Mother”objects 300. As shown by the corresponding text, the “*” in the “1 . . .*” range 312 stands for the reserved word “many” where many representsan integer greater than 1, as in “Mother is related to one or moreChildren”.

The number of “Child” objects 302 need not be a range. For example, auser may simply specify a number (e.g., 3) or parameter (e.g., “n”).Additionally, either end of structural link may specify cardinality.

As shown in FIG. 18, other symbols may feature annotations. For example,a user has annotated the “aggregation” symbol 322 with the reserved term“ordered” 324. This annotation indicates that the left-to-right sequenceof sub-parts 326-330 of the “License” object 320 express an ordering.The corresponding text expresses this relationship as “License consistsof Agreement, Signatures, and Notary Seal, in that order” 420.

As an alternative to intricate annotations, OPM and the tool provide adiagrammatic way of expressing relationships to, potentially, reducediagram congestion. For example, as shown in FIG. 19, instead of anannotation, a user can specify an ordering by “stacking” sub-partsvertically. As the diagrams of FIGS. 18 and 19 are exactly equivalent,the diagrams share the same text 420.

As described above, OPM provides a number of different ways ofexpressing system logic. In addition, OPM also enables a designer toexpress Boolean logic or a “compound condition”. As shown in FIG. 20, Todefine these relationships, OPM again uses the blackened 346 and hollow348 triangles. In the context of connecting object states, however,these symbols represent Boolean AND and OR operations respectively. Thatis, as expressed by the corresponding text 436, symbol 346, connectingstates 352 and 358 to state 342, expresses that the “License” object 240“Valid” state 342 is the Boolean ANDing of the “Signed” Boolean object350 “authentic” state 352 and the “Notary Sealed” Boolean object 356“intact” state 358.

Again, the tool and OPM can model a wide variety of systems. In fact,OPM & OPL can completely specify themselves. For example, FIG. 21illustrates an OPM diagram of OPM/OPL. FIGS. 22 and 23 list acorresponding OPL description of OPM/OPL. This reflective meta-modelingenables rapid modification of OPM and OPL. For example, after coding afirst generation of OPM/OPL that can automatically generate instructionsfor a system, an existing generation of the OPM/OPL system can generatefuture generations of OPM/OPL to reflect enhancements and other changes.

Automatic generation of future versions of OPM/OPL illustrates theflexibility and extensibility of OPM/OPL design. On a less grand scale,the tool may provide a “learning mode” that enables a user or group todefine their own symbols and sentences. For example, in the verticaldomain of a continuous chemical process industry one may define a“sampling” relation shaped like a triangle within which a pie is drawnwith a slice taken out of it. This slice symbolizes the sample, which isa small amount of a large lot that is analyzed for exact composition.The resulting composition is also the composition of the large lot, withits amount practically unchanged. An example sentence would be “Samplerepresents Mixture.” Here, “represents” is the reserved phrase analogousto “consists of” for the aggregation-participation relation.

FIG. 24 illustrates an example of a learning mode. As shown, the toolallows a user to construct a diagram. For example, as shown, the userhas drawn a diagram showing that a “Vehicle” 602 exhibits 604 a“Traveling Medium” 606 of either “water” 610 or “air” 608. Textsentences 622, 624 also describe this configuration.

The user also linked a “Ship” object 616 to the “water” state 610 and an“Airplane” object 618 to the “air” state 608 via hollow triangles 612,614. As described above, hollow triangles 612, 614 representspecialization when connecting things or Boolean “OR”-ing whenconnecting object states, however, in learning mode the tool maytemporarily permit different constructs. After diagramming, the user canenter a text sentence 626 corresponding to the diagram. Similarly, afterentering a new type of sentence 626, the user can draw the correspondingdiagram 600. By identifying reserved words entered by the user andidentifying element labels, the tool can store a diagrammingconfiguration and the corresponding sentence syntax, for example, byautomatically generating new production rules. Thus, the tool can learna new configuration of model elements and their corresponding newsentence. Thereafter, upon detecting a diagram construct, the tool cangenerate a sentence in accordance with the newly defined syntax.Similarly, upon detecting a text sentence having the newly definedsyntax, the tool can generate the corresponding diagram. Thus, thelearning mode gives a user flexibility in using the tool to express newmodeling constructs and concepts. Use of the learning mode may not beavailable to all users, and may be restricted to experts.

OPM can also offer temporal-features, for example, for specification ofsystems that exhibit complex dynamic behavior involving timeconstraints. For example, real-time systems often handle issues likeconcurrency, synchronization among processes, and expression of events,conditions, and timing constraints. OPM provides graphic and textconstructs to include these features in a model.

Referring to FIG. 25, triggering events and guarding conditions arespecified by attaching the letters e and c, respectively, to processlinks which link the triggering or guarding thing (i.e., object orprocess) to the triggered or guarded process. A triggering event cantake the form of an external event, a state-entrance event, astate-change event, a value-change event, a clock event, aprocess-termination event, and a timeout event. For example, FIG. 25illustrates that a “Heating” process takes place upon the occurrence ofa state-entrance event, in which “Room Temperature” enters a state ofbeing below “15° C.” “Heating” occurs if, and only if, the guardingcondition requiring that the “Switch” object remain at state “on”.

OPM also permits representation of temporal constraints and timingexceptions. Temporal constraints are minimum and maximum time bounds ona time interval. Temporal constraints include a process durationconstraint (a constraint on the time spent in executing a process), astate duration constraint (a constraint on the duration of the timespent in an object's state), and a reaction-time constraint (aconstraint on the time elapsed between a triggering event and theexecution of the triggered process). In addition to minimum and maximumtime constraints, a probability distribution function can be specifiedand used for purpose of simulating the entire system. Each entity(object, process, or state) is associated with a multimedia object(image, video clip, audio file, CAD drawing, 3-D hologram, line drawing,schematic, etc.) that goes in action when its time of execution orcreation or destruction comes. Hence, OPM allows for vivid simulations.

Temporal constraints are attributes of the process or state ortransition. They can be expressed by the usual exhibition symbol or byspecifying an interval, T_(min) . . . T_(max), where 0≦T_(min)≦T_(max).T_(min) and T_(max) represent the lower and upper bounds of theinterval, respectively.

Processes take time to execute, and states are situations at whichobjects exist for some period. To be able to specify the time executinga process and being in a state take, both processes and states have animplicit attribute called Duration, which is the amount of time it takesfor a process to execute or for an object to be at a state.

FIG. 26 is a meta-OPD specifying Duration as an attribute of bothProcessing and state of Object. Processing consists of an optionalMinimal Duration and an optional Maximal Duration. Duration exhibitsUnit, which can be millisecond (ms), second (s), minute (min), hour (h),day (d), or year (y). The default is s, so if no unit is specified, itis seconds. Duration also exhibits Distribution, which can be anyprobability distribution with the parameters that are associated withit.

FIG. 27 shows the conventions of denoting minimal and maximal durationon process and state. Like participation constraints on objects, theminimal and maximal duration constraints are separated by two dots: Dmin. . . Dmax. The pair of numbers is recorded below the process or statename, followed by the unit, if it is different than second. The rangeDmin . . . Dmax should be interpreted as a closed range, i.e., [Dmin . .. Dmax]. In a closed range, the lower and upper bounds are included inthe normative range. Parentheses around the range indicate that therange is open, so the bounds are not included. Hence (Dmin . . . Dmax)means that if the process or being in a state takes less than Dmin ormore than Dmax, then the exception process occurs.

FIG. 28 specifies in both graphics and formal English the meta-OPMdefinition of exception handling. The logical XOR relation between theconditions requiring that D<Dmin or D>Dmax, which is denoted by the tipsof the two instrument links arriving at the same point along theException Handling process circumference.

We can view the requirement that D be between Dmin and Dmax as one ofthe post-process conditions and abstract out the entire exceptionhandling mechanism specified in FIG. 28. To do so, we introduce aspecial exception handling link, as described in FIG. 29. In FIG. 29(a)an exception object is generated as a result of Processing taking lessmore than Dmax. A timing exception is a violation of the lower or upperbound of a temporal constraint. A vertical line near the exceptionhandling process end of the link denotes an “Upper Exception Link”. Adouble vertical line-near the exception handling process end of the linkdenotes an “Lower Exception Link”. These exception links connect theprocess or state, the temporal constraint of which was violated, to theexception handling process.

In FIG. 29(b) an Exception Handling process is invoked as a result ofobject being in state more than Dmax. This procedural link is a linefrom the process whose time limits are specified to the exceptionobject.

FIG. 30 depicts an OPM meta-model of temporal processing. The processclass “Timed Processing”, a specialization of the process class“Processing” (described below), features a minimum duration constraintT_(min), a maximum duration constraint T_(max), and an optionalT_(execution)—the time it actually takes to execute the computationaltask within “Timed Processing”. The temporal constraint of “TimedProcessing” from which an exception link emanates is defined as a hardreal-time constraint. Unlike a soft real-time constraint where violatingthe maximum timing does not prevent the process from terminatingnormally, if T_(min)>T_(execution) the process should not terminateearlier than T_(min) allows. The “Delayed Processing” process takes careof this. The “Delayed Processing” process includes “Waiting” and“Outputting” sub-processes. “Waiting” specializes “Timed Processing” bydelaying its execution, such that it meets the minimal durationconstraint. The minimal and maximal waiting times of “Waiting” are T^(w)_(min)=T^(w) _(max)=T_(min)−T_(execution). The second sub-process,“Outputting” behaves like a regular, non-timed process ifT_(min)=T_(max), i.e., T_(min) and T_(max) of the parent “TimedProcessing” are equal. Otherwise, the “Output” sub-process is itself a“Timed Processing” with a T^(o) _(min)=0 and T^(o)_(max)=T_(max)−T_(min), i.e., its minimum duration constraint is zeroand its maximum duration constraint is the difference between themaximum and minimum timing constraint of the parent process.

Before outputting its result, a “Timed Processing” for which T_(max)<∞,i.e., one that has a non-infinite maximum timing constraint, checkswhether this maximum timing constraint is met. If not, i.e., if theprocessing time exceeded T_(max), then it does not output its result. Ifan exception link emanates from that process, a time exception event,i.e., an event signaling the exception of the maximum durationconstraint, is registered.

Again, the temporal features described above have equivalent text (OPL)descriptions in accordance with production rules. For example, atriggering event sentence can take the form “Event event-name of type[event-type] triggers process-name <with a reaction time that is atleast T_(min) and at most T_(max>).” This sentence specifies which eventtriggers the process process-name, and optionally, what the reactiontime constraints are. As described above, OPM/OPL can model virtuallyany system. In addition to its usefulness as a modeling tool, thelegibility and compactness of the OPL text description of a systemenables smooth and direct transformation from original requirements allthe way to executable code that materializes the system's functionalitythrough software (e.g., C++, Java, or other software instructions),database schema definitions, and so forth. Not only is OPL more readableto non-programmer domain experts, but, due to its high level ofabstraction, OPL is also an order of magnitude shorter than theresulting code.

To illustrate automated code generation, FIGS. 31-35 illustrateautomatically generated C++ code that implements the model.

In greater detail, FIG. 31 depicts a system where a “Closing” processchanges the state of a “Door” sub-part of a building elevator from an“open” state to a “closed” state. The corresponding OPL text conciselydescribes this system. The syntax of OPL enables easy parsing of the OPLscript by an OPL compiler. For example, the name of event “Door_open” isa combination of the name of the state whose entrance constitutes atriggering event (open), preceded by the name of the object containingthis state (Door). The event name is followed by the event type, which,in this case is [state entrance], and by the path that leads from thestate “open” of the object “Door” to its root. The root is the closestobject up the structure hierarchy that includes all the features of athing. In the example shown, the root of the object “Door” is“Building”, since “Door” is a part of an “Elevator” and there are two“Elevators” in the “Building”. For this reason, the Elevator'sidentifiers are also specified as [ID in {1 to 2}]. The next part of thesentence is the triggering clause: “ . . . triggers Closing of Door ofElevator[ID] of Building with a reaction time of 4.” This clausespecifies that it is the process “Closing” which is triggered by theevent “Door_open”, specified in the first part of the sentence. Thereaction time constraint (a minimum of 4 seconds and a maximum of 4seconds, abbreviated simply as 4) specifies that exactly 4 seconds mustpass between the state entrance event Door_open and the triggeredprocess “Closing”.

Again, the OPL compiler accepts an OPL script that specifies a systemand automatically converts the OPL script file into C++ code. The OPLcompiler includes modules symbolTable, lexer, parser, emitter, error,and init, which initializes the symbolTable. To allow for efficientcompilation, a pre-processing pass on the OPL script arranges the OPLsentences in depth-first search (DFS) order. In addition to the usualDFS requirements of a tree structure, this DFS order pre-supposes aparticular order of the types of OPL sentences. For example, thefeatures of a thing (object or process) should be specified before itsparts. For example, in the OPL script of FIG. 27, the features of“Elevator”, which are “ID”, “OutstandingRequests”, and “LocationStatus”are fully specified before the part(s) of “Elevator” (e.g., “Door”) arespecified.

The OPL compiler parses the arranged input file in two passes. Duringthe first pass, it generates an intermediate file (simplestate.def),which contains names of stateless objects (objects that do not havestates), along with the path leading to their root. During the secondpass the compiler uses this file to distinguish between two types oftriggering events: state-change events and value-change events. It alsowrites the compiled specification-dependent C++ code into theappropriate C++ output files in an append-only manner.

When the compiler encounters a thing (object or process) it recursivelyparses the OPL sentences that specify that thing. The first OPLsentences processed are structure sentences, which includespecialization sentences, generalization sentences, state enumerationsentences, exhibition sentences, and finally, aggregation sentences. Inthe case of a process, the behavior sentences, which include triggeringevent sentences, guarding conditions sentences, enabling sentences,result sentences, consumption sentences, and effect sentences, areprocessed in this order.

The OPL-to-C++ compiler may proceed according to compilation rules.These rules can handle such issues as the scope of each thing (object orprocess) and its members, the parameters of each method, and so forth.An extended discussion of one example set of compilation rules follows.

All objects inherit, either directly or indirectly, from theabstract-Object class. Major processes can be defined as stand-aloneprocesses, which inherit from the generic Process class, while otherprocesses are defined as methods of other classes. A process can bedefined as a method of an object B if and only if it affects values orstates of objects that are internal to B (i.e., attributes or parts ofB) and has no side effect on objects that are external to B.

Each stand-alone process has two methods—Trigger and Execute, and theattribute Name. The Trigger method checks the process preconditions, andif they hold, calls the Execute method.

The fundamental structural relationships of aggregation andcharacterization are both converted in the same way: If an object B hasa part or a feature (where a feature is an attribute or a method), thatpart or feature is declared as a private member of B. This rule alsoapplies to both simple and complex parts and features.

Each complex object is translated into a C++ class. A complex object isderived, either directly or indirectly (if it is a specialization ofanother object class) from the generic built-in Object class. As shownin the C++ listing of FIG. 32 for the diagram depicted in FIG. 31, theobjects “Building” (line 1), “Elevator” (line 3), and “Door” (line 11),as well as “LocationStatus” and “OutstandingRequests” (not shown) aretranslated into C++ classes.

Simple (i.e., non-complex) OPL objects, such as the object “ID” of typeshort, are defined as private members of the classes to which theybelong (either as features or as parts). The public methods get and set,are defined for each simple object, as shown for “ID” in lines 6-9 ofFIG. 32. Each compound process is compiled into a C++ class that isderived, either directly or indirectly (it is a specialization ofanother process class) from the generic built-in Process class. As anexample, the process “Closing”, which is triggered by the event of the“Door” entering state “open”, is translated into a C++ class, as shownin line 22 of FIG. 32.

A compound process B has the methods Trigger and Execute, whichcorrespond to the sub-processes “Triggering” and “Executing” of FIG. 36(described below). Trigger checks the process guarding conditions. Ifthey hold, the public method Trigger of B calls the private methodExecute of B, which implements the specific process behavior. TheTrigger and Execute methods of process “Closing” are shown in lines 25and 28 of FIG. 32, respectively.

A simple (i.e., non-complex) OPL process is compiled into two methods:process-nameTrigger and process-nameExecute. Like the Trigger andExecute methods of a compound process, the process-nameTrigger methodchecks the process guarding conditions. If they hold, theprocess-nameExecute, which implements the specific process behavior,method is called.

If a complex thing G constitutes a part or a feature of another thing,H, then it is declared as a private class within H. For example, since“Elevator” is part of “Building”, the class “Elevator” is declaredwithin the class “Building”, as shown in line 3 of FIG. 32.

Instances are created for each C++ class, be it an object class or aprocess class. Lines 33, 38, 42 and 45 in FIG. 32 list the instancecreation for the classes “Closing”, “Door”, “Elevator”, and “Building”.Each C++ class also has a constructor method. These constructors arelisted in lines 27, 35, 39 and 43 of FIG. 32.

An OPL state-containing object (i.e., an object that has states) has aC++ pointer to each one of its possible states. Each state belongs tothe generic State class (or its specialized TimedState class, if thestate is timed). For example, line 14 shows the C++ pointer generatedfor the state “closed” of “Door”. For each state, the methodsset_statename (e.g., set_closed) and enter_statename (e.g.,enter_closed) are defined. A set_statename method initializes the stateof an object, (e.g., set_closed initializes state “closed” of “Door”)while enter_statename is used when an object changes its state (e.g.,when “Door” leaves state “open” and enters state “closed”).

For each state-containing object, a get_state ContainingObject method isdefined, which returns its current state. For example, get_Door returnsthe current state of “Door”, which can be either “open” or “closed”.Lines 14-19 show the C++ code generated for the state “closed” of“Door”.

The OPL guarding conditions sentence is checked by the Trigger method.If the guarding conditions hold, Trigger calls the Execute method.Execute uses the enablers of the process, which are specified in theenabling object sentence. Execute transforms objects that are specifiedin the OPL effect, consumption and yield sentences. For example, theguarding condition sentence “Process Closing is guarded by “Door isopen”, “OutstandingRequests of Elevator is yes” and “LocationStatus ofElevator is atFloor” is translated into the Trigger method of “Closing”,as shown in FIG. 33. Trigger checks the different guarding conditionsand combines them according to the AND/OR logical links, which arespecified in the OPD and reflected in the OPL sentences, where ‘,’serves as AND. If the set of guarding conditions hold, Trigger calls theExecute method of the process “Closing”.

An OPL triggering event sentence is translated into part of the C++method “EventProcessTable::TriggerAllProcesses(Event *e)” that builds anEvent-ProcessTable that specifies the triggered process(es) for eachevent.

FIG. 34 depicts the code generated for the OPL behavioral sentence“Event Door_open [state-entrance] of Door of Elevator [ID in {1 to 2}]of Building triggers Closing of Door of Elevator [ID] of Building with areaction time of (4,4).” As shown, the automatically generated C++ codefirst checks the identity of the triggering event. If it is equal to“door_open”, then the identity of the triggering object is checked. Thisidentity can be either Elevator1 or Elevator2. In each case, process“Closing of Door” of the appropriate Elevator is triggered within thespecified reaction time (e.g., 4 seconds).

FIG. 35 illustrates how the OPL effect sentence “Closing affects Door ofElevator from open to closed and LocationStatus of Elevator from atFloorto betweenFloors” is translated into the Execute method of “Closing”,which specifies the way “Closing” affects other objects by changingtheir states.

The code generated by the OPL compiler relies on predefined C++ modules.These modules serve as instruments for a variety of processes.

The predefined modules include the Event and EventQueue Modules forHandling Events and Timeout Events. Each time an event occurs, a recordof it is created and inserted into the EventHistory and into theEventQueue. The event can be internal (e.g., an object entering a newstate) or external (e.g., a user hitting a keyboard character).

An event features the event name and type, the identifier of the objectthat triggered the event, T_(occ)—the time at which the event occurred,and T_(ins)—the time at which the event was inserted into the eventqueue. T_(occ) can be used to check whether reaction time constraints(i.e., constraints on the time elapsed between the event occurrence andthe process triggering) are met. T_(ins) can be used in order to allowthe insertion of future events (such as future timeout events) into theEventQueue.

The EventQueue contains Event objects ordered by T_(ins). When an Eventfirst occurs, both its T_(occ) and T_(ins) are given the value of thecurrent time and the Event is inserted into the EventQueue.

If the Event e1 that is about to be inserted into the EventQueue has aT_(ins1) that is equal to a T_(ins2) of another event, e2, which alreadyexists in the EventQueue, then Event e1 is inserted after Event e2.

When an Event marking an entrance into a time-constrained state occurs,two Events are inserted into the Event Queue: a state-entrance Event anda future state-timeout Event. The Event of type state-entrance isassigned values such that T_(occ)=T_(ins)=T_(now). That is, both thetime of event occurrence. T_(occ), and the time the event was insertedinto the EventQueue, T_(ins), are equal to the present time, T_(now).

The Event of type state-timeout is assigned future time values such thatT_(occ)=T_(ins)=T_(now)+T_(max). That is, both the time of timeout eventoccurrence, T_(occ), and the time the timeout event, T_(ins), are equalto the present time plus the maximum time, T_(max), that should be spentin the time-constrained state.

If the time-constrained state is exited before the maximum time thatshould be spent in the time-constrained state, T_(max), is exceeded,then the future state-timeout Event is deleted from the EventQueue.Otherwise, when the timeout materializes, i.e., the future point in timeequals T_(max), then the state-timeout Event marking this timeout ispopped from the EventQueue.

The predefined modules also include a process module. The genericcompound Process class has a Name attribute, and it contains aconstructor and the two methods Trigger and Execute. Each time theExecute method is executed, a record of an occurrence of Process isinserted into its HistoryRecordSet.

The C++ code generated for the classes TimedProcess and DelayedProcessis based on the generic TimedProcessing process. Process-nameWait andProcess-nameOutput are the C++ names of the “Waiting” and “Outputting”processes, respectively. If T_(execution) is supplied, then the minimaland maximal waiting times of Process-nameWait are T^(w) _(min)=T^(w)_(max)=T_(min)−T_(execution), as are the waiting times of “Waiting”.Otherwise, T^(w) _(min)=T^(w) _(max)=T_(min)−δ; where δ is a smallnumber, in the order of milliseconds, to allow some time for theProcess-nameOutput to execute.

Process-nameWait generates a process termination event, whoseT_(ins)=T_(occ)=T_(now)+T^(w) _(min)−δ. This process termination eventis inserted into the EventQueue, and when popped, triggersProcess-nameOutput. In order to simulate a time exception ofProcess-nameWait, in some small number of randomly selected cases, theprocess termination event of Process-nameWait is given the valuesT_(ins)=T_(occ)=T_(now)+T^(w) _(min)+T_(penalty), where T_(penalty) isthe amount of time that the process is simulated to be late. Inaddition, a process timeout event of Process-nameWait is also insertedinto the EventQueue at the time that the process was supposed to end, atthe latest, namely T_(ins)=T_(occ)=T_(now)+T^(w) _(max).

Since the Process-nameWait method takes close to zero time, the onlytime that the TimedProcesses actually consumes is the time needed for itto compute its output results via the Process-nameOutput method. Thescheduler enables a certain extent of concurrency by using the timeelapsed between the completion of the execution of the Process-nameWaitmethod and the beginning of the execution of the Process-nameOutputmethod.

Before outputting its result, a TimedProcess for which T_(max)<∞, i.e.,one that has a non-infinite maximum timing constraint, checks whetherthis maximum timing constraint is met, allowing a deviation of δ fromT_(max). If not, i.e., if the processing time exceeded T_(max), then itdoes not output its result. If the timing constraint is hard, i.e., ifan exception link emanates from that process, a time exception event,i.e., an event signaling the exception of the maximum durationconstraint, is registered. A better hard time constraint scheme is for aTimedProcess to check the maximum bound during its execution, and if itis violated, register the exception event and terminate the process.This scheme is not implemented in the current version of our compiler.

The predefined modules include a state module. The State class models astate. Each State has the following methods:

(a) The set_state-name method, which sets the attributes (parameters) ofthe state. The attributes include Temporal order, i.e., whether thestate is an initial state (source), a terminal state (sink) or a regularstate; and a Triggering object, i.e., which object (if it is knows aheadof time) triggers the event of entering the state; and

(b) The enter_state-name method which checks if it is possible to leavethe state in which the object is currently in and enter the new state.In case the entrance into the state constitutes a triggering event, thenthe enter_state-name method inserts this triggering event into theEventQueue. This event is deleted from the EventQueue when the state isexited.

A TimedState is a time-constraint State. It has the attributes T_(min)and T_(max) for the minimum and maximum timing constraints,respectively, and T_(last) for keeping the time in which the state waslast entered. If the TimedState has a minimum duration constraint, thenthe TimedState cannot be exited before this time has elapsed. This timeconstraint, T_(now)≧T_(last)+T_(min)−δ³, is checked by the TimedStateTryToLeave method, which is called by the enter_state-name method.

The predefined modules also include a Scheduler module. The Schedulerloops between accepting any arriving external Event (represented bykeyboard strokes or any other external stimuli), and popping an Eventfrom the EventQueue. An Event is always popped from the beginning of theEventQueue, so Events that were inserted earliest into the EventQueueare popped first. An Event can be popped out of the EventQueue only ifthe time of its occurrence, T_(occ), is earlier than the present time,T_(now). Once an event is popped from the EventQueue, it is passed tothe Event-Process Table, which tries to trigger the appropriate Process.If the reaction-time constraints and the guarding conditions of theProcess are met, then the Process is triggered. Once a Process istriggered it is not preempted, i.e., it continues its execution withoutinterruption until finally, it terminates.

The Event-Process Table specifies the Process that should be triggeredby each Event, and the reaction-time constraints on the time elapsedbetween the time of the occurrence of the event, T_(occ), and the timethe appropriate Process is triggered.

If T_(now)−T_(occ)<T_(min), that is, the time elapsed from the time theEvent occurred until it is presently popped from the EventQueue, readyto trigger a process, T_(now)−T_(occ), is less than the minimum reactiontime constraint, T_(min), then the Event is inserted back into theEventQueue. Its T_(occ) does not change, but its T_(ins) is given thepresent time, T_(now).

If T_(now)−T_(occ)>T_(max) then it is too late to trigger the processlinked to the triggering event. In this case, the Event is ignored andis not inserted back into the EventQueue.

If the present time, T_(now), is within the bounds of the reaction-timeconstraints, then the Trigger method of the process that should betriggered by this triggering Event can be executed. Trigger checks theguarding conditions of the process, and if they hold, it calls theExecute method of the process.

If the guarding conditions do not hold but the present time, T_(now), isstill within the bounds of the reaction time constraints (i.e., it willstill be possible to check the guarding conditions at a later time) thenthe Event is inserted back into the Event Queue. The Event now has aT_(ins) value that is equal to the present time, T_(now).

A History module deals with recording the history of Events that weregenerated and Processes that were executed, in the course of theapplication execution. The Mtime class is the time-class used byapplications. Its time granularity is of the order of milliseconds. Itcontains operators for comparing two Mtime objects (e.g., =, ≠, >, <,≧and ≦) and methods for increasing an Mtime object by a given amount oftime.

FIG. 36 is a meta-OPD that shows a generic compound process, calledProcessing. The Processing process generically represents how the toolorganizes information of a diagram, for example, to automaticallygenerate code, provide a simulation, and otherwise make sense of aOPM/OPL model. The right-hand side of this OPD shows an Involved ObjectSet with its two Enabler types and three Transformee types—Affectee,Resultee and Consumee, along with their corresponding procedurallinks—effect link, result link and consumption link. Processing includestwo constituent sub-processes: Triggering and Executing. Each timeExecuting operates a record of an occurrence of Processing may beinserted into a HistoryRecordSet of Processing.

Enablers, who are Agents and/or Instruments, optionally enable theentire Processing process. Their possible involvement in the twosub-processes of Processing can be inferred from the fact that theytouch the outer circumference of the process, rather than just one ofits sub-processes.

Each process has a (possibly empty) Pre-condition Set—a set of logicalconditions that are checked by the process Triggering. A condition canbe a Boolean expression, a test as to whether particular objects are inspecific states required for Execution to take place, and so forth.

The Pre-condition Set can be in a True or False state. The sub-processTriggering checks each condition in the Pre-condition Set. If thePre-condition Set is evaluated to True, then Executing is allowed tostart. The sub-process Executing constitutes the particular behavior ofProcessing (the “body” of theprocedure/function/routine/operation/method). Executing transforms theTransformees of the Processing process. It can change the state of theAffectees via the effect link, it can create the generated Resultees viathe result link, and it can consume the Consumees via the consumptionlink. Executing may require the involvement of one more Enablers ofProcessing—Instruments as well as Agents.

In addition to automatic code generation, the system can provide otherhelpful design features. For example, the tool can use the genericprocessing model of FIG. 36 to provide animated simulations of a modeledsystem to demonstrate modeled execution threads. The simulation can alsoverify design intents and program logic. The simulator can be suited toreal-time systems and accept time constraints of lower and upper boundsof being in a state, duration of a process, or the transition timebetween states. Exceeding these upper or lower bounds triggers andexception handling process. This information is used to run thesimulation.

The simulation can be continuous or step-controlled by the user. Thesimulation starts by the user selecting a subset of things (objectsand/or processes) and specifying states of objects that trigger someprocess. The simulation can depict the state(s) of an object by changingthe color of the current state(s) and use various colors for things(objects and processes) that are in the past, present or future. Thesimulation can indicate continued execution of a process by flashingand/or changing colors of the process ellipse. As soon as the processterminates, all the post-process effects take place (e.g., new objectscan be generated, input objects consumed, change of states, and soforth). The time duration of a process can be fixed or randomly drawnfrom a pre-specified distribution function with given parameters. Inaddition, multimedia artifacts can be switched on or off along withgeneration or destruction of objects or

As an example, consider a simulation of the Wedding process of FIGS. 9and 12. In these diagrams the user specifies the initial conditions ofPerson as being at state “single”. This state is inherited to both theSam and Jane instances of Person. The user also specifies that Justiceand License are present. These are the pre-conditions for the Licenseverifying process. The simulation shows this process as the first totake place by coloring the ellipse of this process red. The timeduration of this process is specified as 10 minutes. The simulationrepresents each 10 minutes as 1 second, so the coloring lasts 1 second,after which only the circumference of the process remains red,indicating this process has passed. The process generates the Booleanobject “License is Legal?”. This object changes its color from gray togreen. A pre-defined distribution function with 0.98 probability ofsuccess is run and determines that “License is Legal”. This is denotedby coloring the “yes” state of the Boolean object. The pre-conditionsfor the “Ceremony Conducting” process are (1) presence of one instanceof “Man” and one instance of “Woman”; (2) presence of “Justice”; and (3)“Legal License”. Since all three preconditions are met, “CeremonyConducting” is triggered and colored red. A normal distribution functionwith a mean of 35 minutes and standard deviation of 15 minutes has beenpredefined. The actual length of the ceremony is computed by thesimulation program to be 40 minutes, so the coloring lasts 4 seconds.Immediately thereafter, two things happen: (1) “Dining” is triggeredunconditionally; and (2) the object “Couple” is now generated, which ismarked by changing its color from gray to green and flashing a couple oftimes. “Dining” is determined to take 120 minutes, so it is colored redand flashes for 12 seconds. Guest Group is hungry as long as the Diningtakes place. This is denoted by the hungry state being colored. As soonas “Dining” terminates, the state “hungry” is uncolored and state “full”becomes colored. This is when the simulation ends. On the average, 1 in50 simulations would end with “Wedding” being postponed due to anillegal “License”.

Automatic code generation and the system simulation features describedabove illustrate potential benefits from the formal expression of asystem in OPM/OPL. Again, at the heart of the system are techniques forgenerating formal text sentences for graphic constructs, and vice-versa.Another benefit of this bi-modal graphic-textual representation of thesystem is the ability of people with various backgrounds and preferencesto relate to the system specification by inspecting either the graphicsor the text and in case some point is unclear at one, the other can beconsulted. No programming background is required as the language is asubset of English and the symbol set is small and intuitive.

FIG. 37 illustrates a process 450 for generating text based on receiveduser input 452, such as user input creating or connecting a graphicelement to another graphic element. A pattern recognition processoperates on the user input and maintains equivalence between thegraphics and the text. The process identifies pre-defined constructionsor symbol arrangements which translate to specific formal Englishsentences types as specified in a pattern lookup table.

As described above, some symbols are graphically overloaded, i.e., theyperform “double” duty. For example, a blackened triangle may indicateaggregation or a Boolean AND, depending on the triangle connections.Thus, the process 450 may determine 454 the context of the symbol, forexample, by identifying other connected or linked symbols. Based on thesymbol and determined 454 context (e.g., pattern recognized from thelookup table), the process 450 identifies 456 a corresponding sentencetype and outputs or updates 450 a formal English sentence using theidentified sentence type and the relevant symbol labels.

FIG. 38 illustrates a process 460 for modifying a graphic depiction of asystem based on received text. The process 460 parses the text, inaccordance with the context-free grammar production rules, to identify,for example, the type of sentence, labeled elements included in the textand so forth. The process 460 can verify that that the sentenceconstitutes a syntactically legal sentence. If not, the system canpresent a set of syntactically correct alternatives for user selection.The process 460 can also notify a user if a sentence semanticallycontradicts a previously existing sentence.

After parsing, the process 460 can identify 464 text elements alreadydepicted in a diagram. For elements not yet depicted, the process 360attempts to identify available workspace area for the addition of newelements. Such attempts may be based on legibility metrics, such as thesize of a closed shape (object, process, state) required to contain itslabel, a penalty for the amount of overlapping of closed shapes,containment requirements (such as states within object, sub-processeswithin a zoomed-in process, etc.), intra-symbol distances, the number ofintersecting links caused by a particular placement, link lengths andnumber of bendings, and so forth. Each metric has a weight and a value.A score is calculated and an objective function is attempted to beoptimized. If a satisfactory space exists 468 (e.g., if the calculatedweighted score of the metric values exceed a threshold), the process 460can add 472 the symbol to the diagram in the identified space andinter-connect 474 the symbol to other elements as specified by the text.If no satisfactory space exists 468, the process 460 can attempt to moveexistent graphic elements to create room. For example, the process 460can identify spaces having the relative best metric scores and attemptto move bordering graphic elements away from these spaces. Each movingof elements is judged again the same set of criteria and a weightedscore of the metric values is calculated.

As described above, OPM/OPL can model a wide variety of systems andpotentially generate/simulate such systems. Additionally, the system canprovide capabilities beyond the realm of modeling. For example, thesystem can aid in translating text from one natural language to another.For instance, FIGS. 39 and 40 illustrate translation of a passage fromEnglish to French.

FIG. 39 illustrates an OPM diagram and corresponding formal Englishdescription of an ATM (Automatic Teller Machine) system. The systemmodel 102 and formal English 104 reflect the following free style prose.

-   -   A consortium consisting of five banks operates an ATM system.        Each bank holds many accounts, one for each customer. An account        is accessible through a cash card. A customer can own one or        more cash cards. The main process the ATM system is designed to        carry out is the execution of cash dispensing an depositing        transactions. Each transaction refers to an account. Executing        the transaction can end up with exactly one of the following two        outcomes: (1) it can yield a (successful) transaction; or (2) it        can issue a denial notice.        As shown in FIG. 39, the element labels and text sentences 104        appear in English.

FIG. 40 displays a copy of the same diagram where the element labelshave been translated to French. Such translation may be performed usinga look-up table storing translations of different words and phrases. Toincrease translation accuracy, the look-up table may includedomain-specific translations. For example, a system model identified asbeing in the finance domain will translate “bank” as “Bankque” insteadof the French word for “River Bank”.

FIG. 40 also shows the corresponding text sentences 104 in formalFrench. In addition to reflecting the translation of element labels, thesentences 104 also feature French reserved words and syntax (e.g., theEnglish “affect” becomes the French “affecte”). The same sentence type(e.g., a state enumeration sentence) may differ in different naturallanguages. For example, one natural language may have a syntax thatorders terms differently than another.

Thus, as shown in FIGS. 39 and 40, to obtain a suitable translation of apassage, a user need only create a diagram of the passage and requesttranslation. The system can then translate the element labels andformulate sentences in the destination language in accordance with thesentence types corresponding to the diagram.

While FIGS. 39 and 40 show translation for a single diagram, a model mayinclude a set of diagrams. For example, the “Transaction Executing”process may encapsulate other entities. It should be understood that thesystem can translate all diagrams in a system model.

FIG. 41 illustrates a computer platform 500 suitable for executingreal-time or batch tool instructions 508. As shown, the platform 500includes one or more processors 502, volatile memory 504, andnon-volatile memory 506. The non-volatile memory 506, such as a harddisk, stores the instructions, for example, after installation from adisk, CD-ROM, or transmission over a network. In the course ofoperation, the instructions 508 are transferred from the non-volatilememory 506 to the volatile memory 504 and the processor(s) 502. Asshown, the platform 500 includes a connection 510 to external devicessuch as input devices (e.g., keyboard, mouse, and so forth) and outputdevices (e.g., a speaker, monitor, an so forth).

The platform 500 also includes a network connection 512 to send andreceive information such as models and model fragments to othernetworked devices. For example, the system can work in a collaborativemode using a coordinated distributed database of the formal Englishand/or corresponding diagram. Users distributed geographically and cancheck-out parts of the model that they can modify and then check-in,while other team members can work on other parts of the system.

The techniques described herein are not limited to any particularhardware or software configuration; they may find applicability in anycomputing or processing environment. The techniques may be implementedin hardware or software, or a combination of the two. Preferably, thetechniques are implemented in computer programs executing onprogrammable computers, each including a processor, a storage mediumreadable by the processor (including volatile and non-volatile memoryand/or storage elements), at least one input device, and one or moreoutput devices.

Each program is preferably implemented in high level procedural orobject oriented programming language to communicate with a computersystem. However, the programs can be implemented in assembly or machinelanguage, if desired. In any case the language may be compiled orinterpreted language.

Each such computer program is preferably stored on a storage medium ordevice (e.g., CD-ROM, hard disk, or magnetic disk) that is readable by ageneral or special purpose programmable computer for configuring andoperating the computer when the storage medium or device is read by thecomputer to perform the procedures described herein. The system may alsobe considered to be implemented as a computer-readable storage medium,configured with a computer program, where the storage medium soconfigured causes a computer to operate in a specific and predefinedmanner.

Other embodiments are within the scope of the following claims.

1-34. (canceled)
 35. A computer-implemented method of architecting,engineering, lifecycle support and/or modeling of a system, the methodcomprising: receiving an input specifying textually requirements of thesystem; modeling the system using meta-libraries containing metamodelsfor domain-specific artifacts as templates for standardized design;linking the requirements to elements of a model of the system; receivingfeedback on coverage of the requirements by the model; simulating themodel of the system qualitatively and quantitatively; modeling one ormore tests for accepting the system; automatically generating one ormore test scripts related to said one or more tests; feeding one or moretest inputs to the system being modeled and feeding results back to themodel; receiving feedback relating quality of the system; based on themodel, computing one or more costs and one or more risks associated withthe system; and automatically generating documentation and one or morecourses of action for one or more parameters of the system at one ormore stages of the system lifecycle.